from the model point of view, it's so useful to have any JSON in the field, but from client(odo, devworkspace) perspective of view, it means that schema does not validate attributes format and every field access requires checking that attributes have the right format, if I did not miss something. So, we need some library code that allows easily to get attribute value as string, int, interface or error if the field has the wrong format.
Am I missing something and it's not going to be an issue for clients to read the attributes?

You're right, I'm looking into it.

To add here, I don't know how elegant or useful embedding full json as an attribute will ultimately be. Even with map[string]string you could ostensibly use json, but the main problem is that it's hard to write. I think I'd rather see something like

attributes:
  controller.devfile.io/plugin/name: "vscode-java"
  controller.devfile.io/plugin/vscode-extensions/java: "https://my-url.com/java.vsix"
  controller.devfile.io/plugin/vscode-extensions/java-debug: "https://my-url.com/java-debug.vsix"

than have the above collapsed into a json blob

attributes:
  controller.devfile.io/plugin: '{"name": "vscode-java", "plugins": ["java.vsix", "java-debug.vsix"]}'

The latter could get quite complicated as there are longer entries. It also forces attributes to be complex, as we couldn't use something like my-attribute: my-value.

than have the above collapsed into a json blob

@amisevsk we just don't need to have json collasped into a JSON blob.
This is a json-like arbitrary value, directly included inside the JSON or YAML document.
So in a YAML document it will a yaml fragment, and in a JSON document it will be a JSON document.

Your example would be:

    attributes:
      name: vscode-java
      plugins:
        - java.vsix
        - java-debug.vsix

That's the whole point of the change.

And with the helpers I'm currently adding to the PR, when getting the GO structs, you would extract it like that:

var Attributes attributes = ...
myName, isAString := attributes.Get("name").Interface().(string)

// And for plugins you might use want to use the `DecodeInto` method, to decode the arbitrary JSON-like structure into a given, well-known GO type. 

plugins := &[]string{}
err := attributes.Get("plugins").DecodeInto(plugins)

// Of course you also have a method to know if a given key is available in the Attributes:

isThere := attributes.Exists("aMissingKey")

This makes sense to me and is a lot cleaner than my suggestion :)

I am wondering if it makes sense to have these helper functions in devfile/api or devfile/library

@maysunfaisal In fact it is there, because my plan was to also use it in the DevfileMetadata struct, which is also in the devfile/api repo, but in the non-K8S-versioned devfile package.

I think we should return the error instead of passing in a struct optionally. This approach makes it very easy to hide ignoring a potential error.

The whole point of this approach is to avoid requiring a multiple value return, in order to be able to chain calls when we know there is no reason for an error.

But here I can change it. I'd be more reluctant to change it for the GetString()... methods, since it's quite useful to be able to chain them or directly use the result in an expression.

Makes sense to me, just wanted to make sure there was a reason for doing it this way.

when we know there is no reason for an error

Can we identify when we know when there is a reason for the error and when there is no?
Like in the shared example amisevsk/devworkspace-operator@use-v1alpha2...davidfestal:use-v1alpha2-and-new-attributes#diff-cee3fd6d4114264b1f235c57bd27c71a9c40cd809efa214a395f5e4cfee8a92fR80
is it safe to propagate an empty string in case the user misconfigured protocol or path as an object?
It shows that such an aproach forces client not to check the erorr. As an alternative, we could have two separate methods(for each type) one would return the error, another will ignore the error but would be named in the way client understand error is suppressed. Like GetStringOrDefault(), default depends on type: string - "", int - 0, interface - {}. <- not the best name since IMHO makes the impression that default is expected as an argument, which also could be a solution for us.

More relevant case, where some boolean value is mistyped by user, like public: "true", instead of public: true. Then user will get unexpected behavior instead of error:

func TestBooleanAsString(t *testing.T) {
	stringMap := Attributes{}.FromStringMap(map[string]string{
		"public": "true",
	})
	publicAttr := stringMap.GetBoolean("public")
	assert.Equal(t, true, publicAttr)
}

Should it be json:"attributes,omitempty"

I was trying to have the free-form attributes at the same level as the main metadata, but this is obviously not really possible.
I finally changed it according to your suggestion in my last commit: 1a8f497